Walkthrough

Enhanced the metatags API to handle TikTok links by detecting short links, following redirects to resolve final URLs, and prioritizing TikTok oEmbed thumbnails over favicons when extracting image metadata for link previews.

Changes

Sequence Diagram

sequenceDiagram
    participant Client
    participant getMetaTags as getMetaTags()
    participant Fetch as Fetch & Redirect
    participant TikTok as TikTok oEmbed
    participant Meta as Metadata Return

    Client->>getMetaTags: Request metadata for URL
    alt TikTok Short Link Detected
        getMetaTags->>Fetch: fetchWithTimeout(url, redirect: follow)
        Fetch-->>getMetaTags: Resolved final URL
        getMetaTags->>getMetaTags: Extract image from HTML
        alt Image is favicon-like
            getMetaTags->>TikTok: Fetch oEmbed thumbnail
            TikTok-->>getMetaTags: Video thumbnail
        else Image is valid
            getMetaTags->>getMetaTags: Use extracted image
        end
    else Non-TikTok URL
        getMetaTags->>getMetaTags: Use standard image extraction
    end
    getMetaTags->>Meta: Return metadata with final imageUrl
    Meta-->>Client: Link preview data

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Poem

🐰 A TikTok hop and redirect too,
No more favicons in our preview queue,
The thumbnail shines where it's due,
Short links resolved through and through! 📹✨

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

• 📝 Generate docstrings

apps/web/app/api/links/metatags/utils.ts (2)

124-132: Double fetch for TikTok short links — response body leaked and URL fetched twice.

Two concerns:

1. Redundant request: The redirect-resolving fetch (line 127) downloads the full TikTok page body only to discard it. Then getHtml(fetchUrl) on line 132 fetches the same resolved URL again. This doubles latency and bandwidth for every TikTok short link.

2. Unconsumed response body: The Response from line 127 is never consumed (res.text(), res.json()) or cancelled (res.body?.cancel()). In Node.js/undici this can delay connection release back to the pool.

Consider refactoring to reuse the response body from the redirect-resolving fetch:

♻️ Proposed refactor — resolve URL and get HTML in one fetch

-  let fetchUrl = url;
-  if (isTikTokShortLink(url)) {
-    try {
-      const res = await fetchWithTimeout(url, { redirect: "follow" });
-      if (res.url) fetchUrl = res.url;
-    } catch {}
-  }
-
-  const html = await getHtml(fetchUrl);
+  let fetchUrl = url;
+  let html: string | null = null;
+
+  if (isTikTokShortLink(url)) {
+    try {
+      const res = await fetchWithTimeout(url, { redirect: "follow" });
+      if (res.url) fetchUrl = res.url;
+      if (res.ok) {
+        const text = await res.text();
+        // Check for Cloudflare challenge
+        if (
+          !text.includes("challenge-platform") &&
+          !text.includes("cf-browser-verification")
+        ) {
+          html = text;
+        }
+      }
+    } catch {
+      // Fall through to normal getHtml path
+    }
+  }
+
+  if (!html) {
+    html = await getHtml(fetchUrl);
+  }

---

129-129: Silent catch {} blocks hinder debugging.

Both the redirect-resolution (line 129) and oEmbed fetch (line 188) silently swallow all errors. The fallback behavior is fine, but a console.warn would help diagnose production failures (e.g., TikTok rate-limiting, DNS issues, timeouts).

💡 Add minimal logging

Line 129:

-    } catch {}
+    } catch (e) {
+      console.warn(`Failed to resolve TikTok short link: ${url}`, e);
+    }

Line 188:

-      } catch {}
+      } catch (e) {
+        console.warn(`Failed to fetch TikTok oEmbed for: ${fetchUrl}`, e);
+      }

Also applies to: 188-188

• X
• Mastodon
• Reddit
• LinkedIn